Skip to content

Support extend#462

Open
sinsoku wants to merge 3 commits into
ruby:masterfrom
sinsoku:support-extend-resolution
Open

Support extend#462
sinsoku wants to merge 3 commits into
ruby:masterfrom
sinsoku:support-extend-resolution

Conversation

@sinsoku

@sinsoku sinsoku commented Jun 21, 2026

Copy link
Copy Markdown
Collaborator

TypeProf did not handle extend, so methods added via extend M were reported as "undefined method" and extend was missing from the dumped RBS.

Implement it symmetrically to include: parse Ruby/RBS extend, resolve the extended module's instance methods as the receiver's singleton methods, and dump extend for class bodies (like include).

Self-referential extend (e.g. extend self) is still unsupported.

sinsoku added 3 commits June 21, 2026 18:01
TypeProf did not handle `extend`, so methods added via `extend M`
were reported as "undefined method" and `extend` was missing from
the dumped RBS.

Implement it symmetrically to `include`: parse Ruby/RBS `extend`,
resolve the extended module's instance methods as the receiver's
singleton methods, and dump `extend` for class bodies (like
`include`).

Self-referential `extend` (e.g. `extend self`) is still unsupported.
Passing a class object where a module it extends is expected
(e.g. `App` to a `(Helpers) -> untyped` parameter) was diagnosed
as "wrong type of arguments", although `App.is_a?(Helpers)` holds
in Ruby. Method resolution and narrowing already recognize
`extend`, so only this typecheck was inconsistent.
The extend scenarios only covered adding `extend` in an editing
session. The removal direction goes through a separate code path
(`remove_extend_def` and the `@extended_modules` cleanup), which
had no regression guard, unlike include's remove-included-module2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant